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Related Applications 

This application is based upon U. S. Provisional Patent Application 
5 Serial Number 60/103,039 filed October 5, 1998. The filing date of U. S. S. N. 

60/103,039 is hereby claimed. U. S. S. N. 60/103,039 is hereby incorporated herein by 
reference. 



Field of the Invention 

10 The present invention relates generally to managing collection and 

delivery of vehicles, and particularly to collection of vehicles fi-om multiple locations 
for disposition through a dispatching system. 

Disclosure of the Invention 
1^ In accordance with the present invention, a system and method of 

managing the collection and delivery of vehicles is provided that can include one or 
more of the following features: 

providing a dispatch management system using a computer and 
software for maintaining and updating information on the status of the vehicles 
20 identified for disposition through the system; 

providing for coupling terminals to the dispatch management system 
firom remote locations, such as order entry terminals at remote customer locations 
coupled by a communication link such as the world wide web; 

recording time stamps for one or more transactions in the process, such 
25 as a time of initial identification of a vehicle for collection, a time at which a vehicle is 
ready for collection from a remote location, a time at which a dispatch request for a 
vehicle was made, a time of actual dispatch of a vehicle, at time of arrival of a vehicle 
at a destination location, etc.; 

providing one or more identifiers for a vehicle being processed through 
30 the system, such as a transaction number and/or a waybill number, etc; 
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defining a dispatch status for a vehicle that is indicative of the status of 
the vehicle, such as "pending dispatch", "ready for dispatch", "dispatched", etc., as 
well as updating the dispatch status for a vehicle as it is processed through the system; 

defining one or more collection attributes of a vehicle indicative of 
5 whether the vehicle is ready for delivery from a remote location, such as "drivable", 
"tow", "body shop", "needs cleaning", "has keys", etc., as well as updating the 
collection attributes for a vehicle as appropriate; 

recording vehicle information for a vehicle being processed through the 
system, such as vehicle identification number, year, make, model, color, etc.; 
10 recording delivery information for a vehicle such as fiael, oil, source 

mileage, destination mileage, etc.; 

assigning one or more drivers for collection of one or more vehicles; 

confirming information fi-om remote locations, such as fax confirmation 
that a vehicle is ready to be picked up fi-om the remote location, and including 
1 5 verification information from previous transactions related to the vehicle; 

generating statistics based on collected information, e.g., average times 
and statistical variations that vehicles spend in a dispatch status such as pending 
dispatch, etc.; 

generating reports based on collected information, e.g., inventory 
20 reports for vehicles by location or regardless of location, reports based on individuals, 
vehicle attributes, locations, or status information, etc.; 

aggregating drivers for multiple deliveries from a remote location; 

automatically determining assignments of drivers based on driver 
information, such as familiarity with locations, dealerships, etc.; 
25 automatically generating documents such as waybills or bills of lading; 

using visual indicia to highlight status information based on a 
predetermined criterion, such as using red text for a pending dispatch status of a 
vehicle; 

generating alerts for status information based on a predetermined 
30 criterion, such as an alert for a vehicle that has a dispatch status value of pending 
dispatch for more than seventy-two hours; 
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validating information required by the system, such as collection status, 
collection attributes, vehicle information, etc.; 

automatically time stamping information; 

automatically changing information based on a predetermined criterion, 
5 such as updating vehicle status from pending dispatch to ready for dispatch based on a 
change in a collection attribute; 

providing for searching for information based on a search criterion, e.g., 
on waybill number, date(s), remote locations, reference names, VTNs, etc.; 

storing information identifying individuals that enter information; 
10 providing for security privileges for entering, changing, and accessing 

information within the system; 

generating a bar code that correlates to vehicle information, so that the 
bar code can be aflSxed, e.g., to a bill of lading and/or to a vehicle; 

scanning a bar code to obtain vehicle information; 
15 updating vehicle information based on scanning a bar code, e.g., 

automatically changing a vehicle status to delivered based on scanning a bar code when 
the vehicle arrives at a destination, or scanning a bar code and designating a change in 
vehicle status such as to ready for dispatch, etc.; and 

generating an invoice to a customer based on stored information, e.g., 
20 automatically invoicing within a twenty-four hour period. 

According to one aspect of the invention, a dispatch management 
system maintains information on the status of vehicles. The system includes a host and 
at least one terminal coupled to the host for the entry of an order for the dispatch of a 
vehicle. 

25 According to another aspect of the invention, a method for maintaining 

information on the status of vehicles includes providing a dispatch management system 
host and at least one terminal coupled to the host for the entry of an order for the 
dispatch of a vehicle. 

Illustratively, the at least one terminal includes at least one order entry 

30 terminal. 

Further illustratively, the information includes a time stamp for 
indicating when a transaction is ordered by a customer. 
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Additionally illustratively, the information includes the status of the 

order. 

Illustratively, the information includes whether placement of the order 
by the customer is complete. 
5 Further illustratively, the information includes whether the vehicle can 

be driven. 

Additionally illustratively, the information includes whether the vehicle 

must be towed. 

Illustratively, the information includes whether a key for operating the 
10 vehicle is available. 

Further illustratively, the apparatus and method include apparatus for, 
and the step of, generating machine-readable code and/or scanning machine-readable 
code for correlating vehicle information and/or updating vehicle information. 

Additionally illustratively, the apparatus and method include apparatus 
15 for, and the step of, creating at least one of a waybill, a bill of lading, an invoice, and 
an identifier for the vehicle. 

Illustratively, the at least one terminal is coupled to the host for the 
entry of an order by a customer. 

Additionally illustratively, the information on the status of a vehicle 
20 includes at least one of: a transaction number; a waybill number; who authorized the 
order; who placed the order; the orderer's account number; the orderer's reference for 
the transaction; where the vehicle is located; where the vehicle is to be delivered; when 
the order was sent to dispatch; when a driver was dispatched to pick up the vehicle; 
the driver's identity; the vehicle's identity; information on the vehicle's fiiel; 
25 information on the vehicle's lubricant; vehicle odometer data at the point of origin; 
vehicle odometer data at the destination; when the vehicle was delivered to the 
destination; the identity of the recipient; and, the dispatch status of the vehicle. 

Further illustratively, the vehicle's identity includes at least one of a 
vehicle identification number; the year of the vehicle; the make of the vehicle; the 
30 model of the vehicle; and, the color of the vehicle. 

Illustratively, the terminal for the entry of an order for the dispatch of 
the vehicle includes a terminal for updating the dispatch status of the vehicle. 
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Additionally illustratively, the information on the status of the vehicle 
includes the assignment of a driver for collection of the vehicle. 

Illustratively, the terminal for the entry of an order for the dispatch of 
the vehicle includes a terminal for at least one of generating order confirmation and 
5 transmitting order confirmation. 

Further illustratively, at least one of the host and the terminal includes 
means for generating at least one of statistics and reports from information collected 
by the system. 

Additionally illustratively, the host includes information from which a 
1 0 driver can be assigned. 

Illustratively, the host includes a host for at least one of creating a 
visual indication based on a criterion and displaying a visual indication based on a 
criterion. 

Further illustratively, the host includes a host for automatically 
1 5 changing information based on a criterion. 

Additionally illustratively, the host includes a host for searching for 
information based on a criterion. 

Illustratively, the host includes a host for identifying individuals who 
modify stored information. 
20 Further illustratively, the host includes a host for controlling access to 

the system for changing information stored in the system. 



Brief Description of the Drawings 

The invention may best be understood by referring to the following 
detailed description and accompanying drawings which illustrate the invention. In the 
drawings: 

Fig. 1 illustrates a screen which is generated by a computer on which a 
dispatch management system according to an embodiment of the invention is run and 
displayed on a monitor associated with the computer; 

Fig. 2 illustrates another screen which is generated by a computer on 
which a dispatch management system according to an embodiment of the invention is 
run and displayed on a monitor associated with the computer; 
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Fig. 3 illustrates a process flow for order entry according to an 
embodiment of the invention; and. 

Fig. 4 illustrates a process flow for dispatch according to an 
embodiment of the invention. 

5 

Detailed Descriptions of Illustrative Embodiments 

Referring now to the drawings, the system is described using the use 
case model. The illustrated system is able to run on Windows NT version 3.5 1 or 4.0 
and Windows 95. The illustrated system is designed to be fault tolerant for continuous 

10 operation. It is capable of displaying all dialogs within twenty seconds of activation. 
As configured, for maximum performance it requires 32 MB of RAM and an Intel 
Pentium processor. 

In this description, the following terms are frequently used. "Actor" 
means any agency that interacts with the system. All actors are provided with security 

1 5 privileges appropriate for the duties performed within the dispatch management system 
by each actor. The actor represents a role played by a person or other system 
component. In order to act within the dispatch management system, an actor must 
have first logged onto the dispatch management system and navigated to the main 
control window of the dispatch management system. "Dispatch management system" 

20 means the software application itself To start the dispatch management system, an 
actor must run the file DMSDTL.exe. A "dispatched screen" contains two tables, 
illustrated in Fig. 1 as grids. The upper table displays the orders sent to dispatch. The 
lower table displays orders that have been dispatched but are not yet completed. A 
"generate reports form" display is a display of all available reports to preview or to 

25 print. A "main control window" is a window that is opened after an actor runs the 
software and logs onto the dispatch management system. The main control window 
contains the menu bar and toolbar that permit users to initiate all major system 
activities. A "maintain accounts form" contains all related information for customer 
accounts. A "maintain users screen" contains all related information for the user 

30 system accounts, such as user name, password, security access rights, and so on. 

A "maintain DMS settings form" contains all options available for 
dispatch management system configuration and permits the system administrator to 
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modify and save system parameters. An "order form" contains all related information 
for an order. An illustrative order form according to the invention is illustrated in Fig. 
2. An "order search form" contains a grid view of the orders list with columns that 
display searchable fields. A "pre-condition" of a use case is the state in which the 
5 system must be prior to performance of a use case. A "post-condition" of a use case is 
the state in which the system will be immediately after performance of a use case. A 
"requisitioner" is an entity that places a pickup request. The requisitioner's name is 
captured in the "order by" field of an order form. An actor selects a requisitioner fi-om 
the stored list that is maintained by the system administrator. A "special requirement" 

10 is a non-fiinctional requirement that is specific to a use case but is not easily or 
naturally specified in the text of the use case's event flow. Examples of special 
requirements include performance, usability, reliability and supportability requirements. 
A "splash screen" is the screen that appears for a brief interval, illustratively three 
seconds, after an actor has launched the dispatch management system. A 

1 5 "supplementary requirement" is a non-fijnctional requirement that is common to all use 
cases in a dispatch management system. Examples of supplementary requirements 
include performance, usability, reliability and supportability requirements. A "use 
case" is a sequence of actions that a dispatch management system performs that yields 
an observable result of value to a particular actor. 

20 The following actors may interact with the dispatch management 

system. A "dispatcher" receives orders fi*om order entry personnel, reviews the orders, 
and has the ability to sort orders. A dispatcher may sort orders by, for example, date 
and time ordered, vehicle identification number or VTN, point of origin including 
address, destination, drivable or tow status, and date and time dispatched. The 

25 dispatcher is capable of making updates to order data. The dispatcher assigns a lead 
van driver. The dispatcher prints bills of lading in appropriate quantities, one for each 
vehicle, for lead van drivers. The dispatcher receives the valid order after the order 
entry person presses the save button or presses a shortcut key to save an order, or 
after the order entry person presses the "send to dispatch" button on the order form. 

30 "Order entry personnel" receive pickup requests fi-om vehicle sources, 

such as vehicle factories, vehicle dealers, and the like. Order entry personnel enter 
order data. Order entry personnel verify v^th vehicle sources that vehicles are ready 
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for pickup. Order entry personnel transmit confirmations, for example, by facsimile, to 
vehicle sources of their orders. Order entry personnel send orders to dispatch. Order 
entry personnel can initiate the basic flow and all alternative flows of the "manage 
orders" use case. A "lead van driver" accepts a quantity of bills of lading firom a 
5 dispatcher and assembles an appropriate number of drivers. A "system administrator" 
maintains all configuration parameters of the dispatch management system and user 
accounts. 



"manage orders" use case is initiated by an order entry person to create a new order, 

10 review an existing order, modify an existing order, cancel an existing order, find an 

existing order, send confirmation of an order to a vehicle source, and send an order to 
dispatch. Actors can initiate the basic flow and all alternative flows of the "manage 
orders" use case. The "manage orders" use case starts when an order entry person 
opens an order form. The order form contains the status of the order. It indicates 

1 5 whether the call placing the order is completed. It indicates whether the vehicle is 

drivable, whether keys are available, and whether data on the vehicle has been ordered. 
The order form identifies the transaction number and the waybill number. It indicates 
who authorized the order, who placed the order, the orderer's account number and the 
orderer's reference name/number. The order form indicates the origin, that is, where 

20 the vehicle is, including a contact name, telephone number, and the name and address 
where the vehicle is to be picked up. The order form indicates the destination, that is, 
where the vehicle is to be delivered, including the name, address and telephone 
number. The order form also identifies the date and time the order was sent to 
dispatch, the date and time a driver was dispatched to pick up the vehicle, the driver's 

25 identity, typically by a driver number, the last eight characters of the VIN, and the 
year, model and color of the vehicle. A field is provided on the order form for 
comments. The order form indicates how much fiiel is in the vehicle, whether it has 
sufficient lubricant, the odometer mileage at the point of origin, the odometer mileage 
at the destination, the date and time the vehicle was delivered at its destination, and the 

30 identity of the recipient. If no activity is selected by the order entry person, the order 
form displays the current saved order for review. When the order form is opened, it 
displays the first saved order, or a blank order if no orders have been saved. The order 



The use case model is described by the following descriptions. The 
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entry person can navigate to the first, last, next and previous orders using toolbar 
buttons and shortcut keys. The dispatch management system displays the available 
activities and permits the user to select: "add new" (to create a new order); "edit" (to 
modify an existing order); "find" (to locate an existing order); "cancel" (to cancel an 
5 existing order); "fax confirmation" (to facsimile transmit to a vehicle source 

confirmation of an order); and "send to dispatch" (to transmit an order to dispatch). 



order form or on the toolbar, or by using a shortcut key, the dispatch management 
system disables all other action selection until the transaction is completed. The user is 



number, or transactional sequence number, and date ordered. These fields are read 
only. The dispatch management system enters the name of the user who is logged on 
in the "authorized by" field of the order form, and enters the default destination's fiill 
address. The user can edit the default destination's address field. The user must then 

15 complete the "order by" field by selecting fi-om the requisitioners list, the reference 

name, the account number, the origin fields including contact name, and search for the 
origin phone number in the account table. If the account exists in the account table, 
the dispatch management system fills in the name and address fields. Otherwise, the 
user must fill in the name and address fields, afl:er which the dispatch management 

20 system adds a new origin account record when the order is saved on the dispatch 

management system. The user adds the last eight characters of the VTN, and the year, 
make and model of the vehicle. The user can edit or update the "is call requh-ed" field, 
the "status" field, the "drivable" field, the "keys" field and the color field. The user 
then chooses either to save the order or cancel it. The user presses the save button or 

25 presses a shortcut key to save. The system validates required fields, adds a time 
stamp, and saves the order information. The order appears on the dispatch screen. 
The "manage orders" use case begins again. 



system informs the user that one or more required fields have been lefl; blank. The user 
30 can then enter the necessary information and save the order or cancel the order. If the 
value of the "is call required" field is "yes" or the value of the "status" field is not 
"ready" or the value of the "drivable" field is null or the value of the "drivable" field is 



If "add new" is selected, either by chcking on the "new" button on the 



10 



able to save or cancel an order. The dispatch management system generates a waybill 



If one or more required fields are lefl: blank, the dispatch management 
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null or the value of the "keys" field is null, the order status is set to pending. The user 
is informed that the order has been saved as pending, and the system displays the order 
on the pending screen. If the user wishes to cancel an order, the user presses the 
cancel button or shortcut key. The system asks the user to confirm the cancel order 
5 instruction. If the user confirms, the order status is changed to "canceled." The 
"manage orders" use case begins again. 

The user may modify an order by clicking either the modify button on 
the order form or on the toolbar, or by using a shortcut key. Only users with 
appropriate security can update the order fields. The dispatch management system 

10 inhibits editing of the destination address fields; the reference name; the account 

number; the contact name; the phone number; the last eight characters of the VIN; the 
year, make and model; the "is call required" field; the "status" field; the "drivable" 
field; the "keys" field; and the "color" field. To update the order fields, the user places 
the cursor in the field to be updated using the tab key or mouse. The dispatch 

1 5 management system permits editing when a valid editing field is selected. After 
editing, the user presses the save button or a shortcut key. 

The user may find an order by clicking either the find button on the 
order form or on the toolbar or by using a shortcut key. The order search form opens 
as a modal dialog window containing a grid view of the orders list with columns that 

20 displays searchable fields. The searchable fields are: waybill number; date ordered; 
origin name; reference name; account number; and last eight characters of the VIN. 
The user can change the sort order by pressing the tab key and selecting an active 
colunm. The user can navigate back and forward by pressing arrow up and arrow 
down keys or using the mouse. The user can do incremental searching on the active 

25 field by typing on alphanumeric keys. The user presses the "ok" button to select an 
order and return to the order form or the "cancel" button to cancel a search. The 
"manage orders" use case begins again. 

The user can send facsimile confirmation by clicking the "send fax" 
button on the order form. The dispatch management system generates a text file that 

30 contains waybill number, date ordered, "authorized by," "ordered by," full address of 
origin, lead driver, full address of destination, reference name, account number, 
contact name, last eight characters of the VIN, year, make, model and color, and 
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special instructions. This file is then printed to the facsimile printer. The facsimile 
printer can be a fax modem with a printer driver, or a printer assigned as the facsimile 
printer by the system administrator. The "manage orders" use case begins again. 

Order entry personnel can send an order to dispatch by clicking the 
5 "send to dispatch" button on the order form. The dispatch management system 

validates the required fields, changes the order status to "ready," adds a date and time 
stamp, and saves the order information. If the system detects the field "is call 
required" set to "yes," the order status is "not pending," the "drivable" field is empty, 
or the "keys" field is empty, it disables the "send to dispatch" button, and the "send 
10 order to dispatch" button is disabled. The system permits the "send order to dispatch" 
action if the order status is "pending," the field "is call required" is set to "no," the 
field "drivable" is set to "drive" or "tow," and the field "keys" is set to "has keys" or 
"no keys." The valid order appears on the dispatch screen. The "manage orders" use 
case begins again. 

15 Order entry personnel can cancel an order by clicking either the 

"cancel" button on the order form or on the toolbar, or using a shortcut key. The user 
is asked to confirm the cancellation of the order. If the "cancel" command is 
confirmed, the order is marked as canceled. The dispatch management system permits 
cancellation of the order if its status is "pending," "ready," or "dispatched." Orders 

20 with "canceled" or "completed" status cannot be canceled. The "manage orders" use 
case begins again. The user presses the "save" button or presses a shortcut key to save 
an order. 

An illustrative process flow for order entry is illustrated in Fig. 3. 
Pickup requests are received firom various factories and other entities and might 

25 include activities such as facsimile receipts for orders, computer generated orders, 
courier service-deUvered orders, and so on. Information entered in the order form is 
derived fi-om these pickup request documents. The availability of one or more vehicles 
is verified with the vehicle's (s') source, for example, an automobile dealership, by 
telephone contact with the source. Specific information is eUcited during such 

30 telephone contact, for example, is the vehicle ready, is it drivable, must it be towed, are 
keys available, and so on, as well as the identity of the person who is providing the 
information concerning vehicle readiness. Should the vehicle not be ready for pickup, 
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the order form includes fields for the entry of the reasons why, and the request is 
characterized as "pending," and cannot be dispatched until resolution of all of the 
readiness criteria. The dispatch management system premits a facsimile confirmation 
to be provided to the source of the order. This confirmation is intended to reduce 
5 wasted effort dispatching personnel to pick up vehicles which cannot be picked up. 
The facsimile confirmation includes specific language relating to the readiness of the 
vehicle and confirms the telephone conversation between dispatch management system 
personnel and the contact who ordered the pickup. This facsimile confirmation is 
believed best achieved using a fax modem in order to make it as effortless as possible. 

10 Orders are sent to dispatch by order entry personnel after completion of the required 
fields of the order and confirmation between dispatch management system personnel 
and the contact who ordered the pickup that the vehicle is ready for pickup. The 
paperless order is sent to dispatch by clicking on a designated command. The 
command to dispatch is date and time stamped. 

1 5 The "dispatch" use case is initiated by a dispatcher to assign lead 

drivers, review orders and enter dehveiy times for completed orders. This use case is 
initiated by the dispatcher opening the dispatch form illustrated in Fig. 1 . A dispatcher 
can initiate the basic flow and all alternative flows of the "dispatch orders" use case. 
As previously noted, the dispatch form contains two table grids. The upper grid 

20 displays the orders that have not been dispatched. Order status is "ready" or 

"pending." The grid contains columns assigned to: transaction number; address of 
origin; whether the vehicle is drivable; the time ordered; the destination address; the 
make; the model; comments; the identity of the lead driver; the time dispatched; and 
the status. Orders that have "pending" status and having less than seventy-two hours 

25 since the transaction was initiated are displayed with grey background. Pending orders 
having seventy-two or more hours since the transaction was initia.ted are highUghted. 
Orders having "ready" status are displayed with white background. The lower grid 
displays orders that have been dispatched but have not yet been delivered. These 
orders have "dispatched" status. This grid contains the same columns as the upper 

30 grid, and includes a "time delivered" field. These orders are displayed with white 
background. The dispatcher places the cursor in the "lead driver" field to enter a 
driver number. The dispatcher can then select the next record using the mouse or an 
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arrow key, and enter a driver number again. If the current order has "ready" status, 
the dispatch management system enters the "time dispatched" field with the current 
date and time and updates the "status" field value to "dispatched." The dispatcher 
clicks on the "save" button. The system commits the changes to the "order" table and 
5 refi-eshes the order form. The orders that have been dispatched are displayed in the 
lower grid. New orders that have been entered since the last transaction appear in the 
upper grid. The "dispatch orders" use case begins again. 

The dispatcher can change the sort order of the "not dispatched" orders 
by selecting one of the following options: origin name; destination name; or, time 

10 ordered. The dispatch management system refi-eshes the data in the grid and changes 
the sort order of the order records by the selected field. The "dispatch orders" use 
case begins again. The dispatcher can change the sort order of the "not yet delivered" 
orders by selecting one of the following options: origin name; destination name; time 
ordered.; time dispatched; or, lead driver. The dispatch management system refreshes 

1 5 the data in the grid and changes the sort order of the order records by the selected 
field. The "dispatch orders" use case begins again. The dispatcher can enter the 
delivery date and time by selecting the order to be edited in the lower grid and entering 
the date and time when the vehicle was delivered. The dispatch management system 
updates the status field to "completed," The dispatcher can double click on the 

20 "delivery time" field to fill in the current date and time. The dispatcher then clicks on 
the "save" button. The dispatch management system then commits the changes to the 
"order" table and refi-eshes the form. Orders that have been delivered are not 
displayed. Orders that have been dispatched since the last transaction appear in the 
lower grid. The "dispatch orders" use case begins again. To close the dispatch form, 

25 the dispatcher clicks on the "close" button on the form or uses a shortcut key. The 
dispatcher is asked to save changes. If the dispatcher selects "save," the dispatch 
management system commits changes to the database before closing the form. 
Otherwise, the changes are not saved. The "dispatch orders" use case ends. The 
dispatcher may assign drivers to orders with pending status. The dispatch management 

30 system discards unsaved changes and sets the unsaved driver status to zero. The 
dispatcher may revoke a driver assignment on an order that has been dispatched but 
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has not yet been committed by changing the driver number to zero. The system resets 
the order status to "ready" and the time dispatched to null. 



the "close" button or using a shortcut key. The dispatcher is asked to save changes to 
5 the dispatch order form. If the dispatcher selects the "save" option, the system will 
save the updates before closing the form. Otherwise, changes will not be saved. 



dispatcher received orders from order entry personnel The order appears on the 
dispatcher's screen. The dispatcher reviews the dispatch screen on an ongoing basis, 

10 typically sorting orders by various methods, such as ordering entity, location, date of 
order, and so on. Dispatch information may be created for consignment orders. 
Information such as "call for residential pickup" may also be added. The dispatcher 
assigns lead van drivers to pick up vehicles based on different criteria, such as van size, 
familiarity with a particular location or dealership, and so on. The dispatcher will add 

1 5 this information to the dispatch screen. The dispatcher will print bills of lading in 
appropriate quantities, one for each vehicle, for the lead van drivers. The bills of 
lading typically will be provided with bar code decals for use in later identification and 
tracking of vehicles. The lead van drivers travel to the vehicle points of origin, locate 
the vehicles to be transported, apply the appropriate bar code decals to these vehicles, 

20 note particular information on the vehicles themselves, for example, on the driver's 
side windshields of the vehicles, inspect the vehicles, leave copies of the appropriate 
bills of lading inside the vehicles, and assign drivers to transport the vehicles. The 
drivers then transport the vehicles to the auction gate for check-in. A remote bar code 
scanner located at the check-in station scans the code bars on the decal previously 

25 applied by the lead driver, the vehicle is entered into the auction's data base, and the 
entry is time and date stamped. The driver returns a copy of the bill of lading for the 
vehicle he or she has transported to the billing clerk along with any ancillary charges 
such as fuel, oil, change in tow/drive status, and so on. The clerk reviews the bills of 
lading and applies appropriate charges to approved accounts. The billing clerk then 

30 prepares invoices. These typically will be prepared within twenty-four hours of 
delivery, and will include particular information, such as a simimary of the vehicles 
picked up, delivered, vehicle identification numbers, and so on. 



The "dispatch order" form can be closed by the dispatcher clicking on 



An illustrative process flow for dispatch is illustrated in Fig. 4. A 
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The dispatch management system permits the customer to determine 



online the status of an order. This ability results in significant time savings and permits 
customer personnel who otherwise would have to expend considerable effort tracking 
orders to engage in more productive activities, such as tracking soon-to-expire leases 
5 and so on. In addition, the Internet version of the dispatch management system 

permits the customer to print reports on the current status of the customer's business. 
With a user i.d. and password, the customer can detemiine the status and disposition 
of vehicles in the customer's inventory essentially in real time. For example, at an 
automobile auction, dispatchers can monitor many orders which can be sorted by, for 

10 example, zip code, city or state. This permits dispatchers to work logistically much 
more efficiently than prior art manual systems would permit. As well, the Internet 
activity permits multiple auctions to reside within the same database through a server, 
thereby achieving the logistical efficiency of a single location. In another words, a 
team of dispatchers, for example, can study the dispatch management screens and 

15 watch multiple auctions for logistical efficiencies, so that resources such as people and 
trucks retrieving automobiles being auctioned can be utilized with minimum waste. 
Dispatchers will be afforded many more opportunities to put together efficient runs to 
transfer automobiles. As well, from a dispatching operations standpoint, the user can 
create databases of how vehicles move through the process and how buyers and sellers 

20 handle these vehicles. In other words, firom a management standpoint, a user can 
watch various auctions to determine how long it takes, for example, for a particular 
auction to retrieve vehicles as compared to other auctions, and correlate this data with, 
for example, auctions' locations. The user can then factor in other elements that may 
aflfect an auction's efficiency. This provides the user with a management tool that 

25 helps the user to know where to focus efforts to improve auction efficiency. The 

dispatch management system also permits users to create their own reporting through 
the dispatch management system's reporting features. This permits users to respond 
and be proactive with their customers fi-om a management standpoint. It permits users 
to compare the success of various auctions whose success they wish to evaluate, for 

30 example, according to a number of different criteria by which the dispatch management 
system is capable of sorting. 
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The dispatch management system also contemplates a scanning 



operation having multiple options. A vehicle can complete its cycle in the dispatch 
management system software, by manually clearing the vehicle if user personnel have 
first-hand knowledge that the vehicle is there, or a vehicle can complete its cycle by 
5 scanning. Scanning can be in the form of hand scanners stationed at various entry and 
exit points to and from an auction, or stationary scanners, to read bar codes applied to 
the cars. For example, a vehicle could trigger a bar code scanner to begin 
interrogating the vehicle for a bar code when the vehicle drives over, for example, an 
entry and exit coil or metal detector. In another example, a vehicle could interrupt a 

1 0 beam of an injfra-red system to trigger a bar code scanner to begin interrogating the 
vehicle for a bar code. Once a bar code is read, a computer running the dispatch 
management system would conduct a query whether the code is a valid code for that 
destination. This happens very quickly. If the code is a valid code, the driver would 
enter an identity, for example, by using a machine readable identification card, for 

1 5 example, a proximity card, or by entering a thumb print or the like. This would credit 
the driver for moving that car. 



would change fi*om red to green and a computer located in close proximity would send 
a signal to the arm gate. The arm gate would open and permit the vehicle to pass 

20 through, after which the arm gate would close again. The bar code also permits an 
entry/exit station i.d. to be transmitted so that a vehicle, once it is logged in to an 
auction, could pass through other stations having their own unique i.d.'s or bar code 
reading fiinctions, such as hand scanners, at, for example, a body shop or a 
reconditioning shop. Amounts allocated to specific cost/price fimctions could then be 

25 fed to a central computer and posted as charges to a particular car. This feature can 
also be used for locating vehicles within a facility. For example, an auction can restrict 
lanes so that vehicles pass through the restricted lanes in facility parking areas and pass 
scanners of the general types previously described at various locations in the parking 
areas, providing indications of where the vehicles are within the facility. 

30 An illustrative system thus permits a user to: view and edit shipment 

data; maintain a consignor database; keep records; provide instant access to records; 
virtually eliminate handwritten orders; provide immediate knowledge of the locations 



Once the vehicle and driver have been cleared, a light at the arm gate 
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of vehicles; whether personnel have been dispatched to retrieve vehicles, and the status 
of those dispatched orders; obtain complete order entry, for example, account number, 
reference, orderer's name, and so on; obtain alerts concerning pending pickups and 
incomplete orders; have instant access to proof of delivery; virtually immediate 
5 confirmation of orders; print statistical reports; save labor in taking orders; and, 
provide checks on vehicle log-in, maintenance and inventory processes. 



higher. It can use a separate server and share existing lines. It uses code 39 bar code 
scaiming equipment. It can use remote hard wired or RF scan guns. It has a 33.6 K or 
10 faster modem, an SVGA monitor with 600 x 800 resolution, and a backup tape drive 
of 2 GB or higher capacity. An illustrative server has 64 MB RAM, 50 MB disk space 
and a 4.3 GB hard drive. Illustrative clients have 16 or 32 MB RAM, 50 MB disk 
space and 2. 1 GB hard drives. 



Illustrative hardware shares an existing network with OS NT 3.51 or 



